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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

To ensure competitiveness in a longer time frame an evolution of the overall 3GPP system needs to be considered. 

This document compiles requirements to ensure that an Evolved Packet System can cope with the rapid growth in IP 
data traffic and demanding requirements for new multimedia type of applications in terms of performance and quality, 
delivered to the user, whilst at the same time enabling cost effective deployment and operation. 

The Evolved Packet System is characterised by: 

- Reduced latency 

- Higher user data rates equating to broadband performance 

- Improved system capacity and coverage 

- Lower operational costs 
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1 Scope 



The present document describes the service requirements for the Evolved Packet System. Additional requirements for 
E-UTRAN are contained in the specifications identified in annex B. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.003: "Circuit Teleservices supported by a PubHc Land Mobile Network (PLMN)". 
[2] 3GPP TS 21.905: "Vocabulary for 3GPP specifications". 

[3] 3GPP TS 22.258: "Service Requirements for the All-IP Network (AIPN); Stagel". 

[4] 3GPP TR 25.913: "Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E- 

UTRAN)". 

[5] 3GPP TS 22.1 15: "Service aspects; Charging and billing". 

[6] ETSI TS 102 250-1: "Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects 

for popular services in GSM and 3G networks: Part 1: Identification of Quality of Service 
aspects". 

[7] 3GPP TR 23.882: "3GPP system architecture evolution (SAE): Report on technical options and 

conclusions". 

[8] C.SOOOl-A Introduction to cdma2000 Standards for Spread Spectrum Systems - Release A. 

[9] C.S0002-A Physical Layer Standard for cdma2000 Spread Spectrum Systems - Release A. 

[10] C.S0003-A Medium Access Control (MAC) Standard for cdma2000 Spread Spectrum Systems - 

Release A addendum 2. 

[II] C.S0004-A Signaling Link Access Control (LAC) Specification for cdma2000 Spread Spectrum 
Systems -Addendum 2. 

[12] C.S0005-A Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems 

- Release A addendum 2. 

[13] C.S0006-A Analog SignaHng Standard for cdma2000 Spread Spectrum Systems - Addendum 2. 

[14] A.S0007 - A.S0009 Interoperability Specification (lOS) for High Rate Packet Data (HRPD). 

[15] A.SOOl 1 - A.S0017 Interoperability Specification (lOS) for cdma2000 Access Network 

Interfaces. 

[16] X.SOOl 1 cdma2000 Wireless IP Network. 

[17] C.S0024-A cdma2000 High Rate Packet Data Air Interface Specification. 

[18] C.S0024-0 cdma2000 High Rate Packet Data Air Interface Specification. 
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[19] Void. 

[20] WiMAX Forum Mobile System Profile, Release 1.0 . 

[21] 3GPP TS 22.101: "Service Aspects; Service Principles". 

[22] "Recommendations and Requirements for Networks based on WiMAX Forum CertifiedTM 

Products" (WiMAX stage 1) 

[23] "WiMAX Forum Network Architecture (Stage 2: Architecture Tenets, Reference Model and 

Reference Points)" 

[24] "WiMAX Forum Network Architecture (Stage 3: Detailed Protocols and Procedures)" 

[25] Void. 

[26] S.R0048-A 3G Mobile Equipment Identifier (MEID) 

[27] Void. 

[28] Void. 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [2] and the following apply. 

Evolved Packet System: is an evolution of the 3G UMTS characterized by higher-data-rate, lower-latency, packet- 
optimized system that supports multiple RATs. The Evolved Packet System comprises the Evolved Packet Core 
together with the evolved radio access network (E-UTRA and E-UTRAN). 

Service Continuity: The uninterrupted user experience of a service that is using an active communication (e.g. an 
ongoing voice call) when a UE undergoes a radio access technology change or a CS/PS domain change without, as far 
as possible, the user noticing the change. 

Note: In particular Service Continuity encompasses the possibility that after a RAT / domain change the user 
experience is maintained by a different telecommunication service (e.g. tele- or bearer service) than before the RAT / 
domain change. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [2] and the following apply. 

NRT Non Real Time 

RT Real Time 
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General description 



4.1 Objectives 



The Evolved Packet System is a higher-data-rate, lower-latency, packet-optimized system that supports multiple RATs. 
The focus of the Evolved Packet System work is on enhancement of Packet Switched technology to cope with rapid 
growth in IP traffic. 

The objectives of the Evolved Packet System are to: 

- Provide higher data rates, lower latency, high level of security and enhanced QoS; 

- Support a variety of different access systems (existing and future), ensuring mobility and service continuity 
between these access systems; 

- Support access system selection based on a combination of operator policies, user preference and access network 
conditions; 

- Realise improvements in basic system performance whilst maintaining the negotiated QoS across the whole 
system; 

- Provide capabilities for co-existence with legacy systems and migration to the Evolved Packet System. 
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5 High-level requirements - user and operational 

aspects 

The Evolved Packet System shall be capable of accommodating a variety of different access systems thus providing a 
multi-access system environment to the user. 

The Evolved Packet System shall provide mobility functionality within and across the different access systems. 

The Evolved Packet System shall provide capabilities to support the efficient integration of E-UTRAN PS Core 
Network Nodes and GERAN/UTRAN PS Core Network Nodes. 

The Evolved Packet System shall optimize mobility functionality meaning that it shall offer minimal signalling 
overhead, minimal handover interruption time, secure handover procedure and local breakout. 

The Evolved Packet System shall provide capabilities to inter- work with a variety of broadband networks based on IP 
technologies including those not specified by 3GPP. 

The Evolved Packet System shall provide enhanced performance e.g., low communication delay, low connection set-up 
time and high communication quality. 

The Evolved Packet System shall be able to efficiently support a variety of traffic models e.g. user-to-user, user-to- 
group and traffic models generated by ubiquitous services. 

The Evolved Packet System shall provide functionality to support outbound roaming subscribers on other Evolved 
Packet Systems and legacy networks. 

The Evolved Packet System shall provide functionality to support inbound roaming subscribers from other Evolved 
Packet Systems and legacy networks. 

The Evolved Packet System shall be capable of supporting and inter- working with PS services provided on Rel-7 and 
earlier networks. The Evolved Packet System shall be capable of inter-working with CS services provided on Rel-7 
and earlier networks. 

The Evolved Packet System shall support service continuity between 3 GPP access systems and also between 3 GPP 
access systems and non 3GPP access systems whether the UE supports simultaneous radio transmission or not. 

The Evolved Packet System shall be able to accommodate fixed access systems and to inter- work with fixed networks 
in order to provide service continuity over fixed/mobile converged networks. 

The Evolved Packet System service capability set shall include, as a minimum, support for the following categories of 
services that are likely to be used by the majority of operators: 

- Voice 

- Video 

- Messaging 

- Data file exchange 

The Evolved Packet System shall provide for efficient usage of system resources, especially of radio resources through 
both signalling and transport optimization, e.g. overhead, terminal power, radio resources, mobility state, signalling 
load. 

The Evolved Packet System shall support efficient delivery of text-based broadcast messages received from a legacy 
CBC. 

The Evolved Packet System shall support E-UTRAN only operators. The system shall allow these operators to offer 
national roaming to their subscribers. 

The Evolved Packet System shall be capable of uniquely identifying each device that connects via 3GPP access 
networks and 3GPP2 access networks. For a dual mode device supporting both 3GPP and 3GPP2 access technologies. 
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there shall be a single persistent identifier used to identify the device. This device identifier shall be the same even when 
the device moves between 3GPP and 3GPP2 access types. 

Note: The 3GPP2 device identifier structure is consistent with the IMEI structure [26]. 

The EPC shall be capable of restricting access of specific 3GPP devices, 3GPP2 devices and dual mode 3GPP/3GPP2 
devices. 

5.1 Requirements for Fixed Mobile Interworking 

The Evolved Packet System shall support the following scenarios: a single Operator offering both fixed and mobile 
access; different Operators collaborating to deliver services across both networks. These scenarios will be supported by 
interworking between the access networks. 

The Evolved Packet System shall support access to services on the mobile network via interworking with a fixed access 
network for the following scenarios: 

Residential scenarios for operators that own both wireless and wireline access networks 

- Residential scenarios for operators that own wireless access networks only 

Enterprise scenarios with managed connectivity between mobile operators and enterprise networks 

The Evolved Packet System shall be able to support the following functions for interworking between the fixed access 
in the above scenarios and Evolved Packet Core: 

- connectivity, 

- subscriber authentication/authorization, 

- offline charging 

- online charging for traffic routed via the Evolved Packet Core 

- Policy Control and 

- Quality of Service. 

The Evolved Packet Core shall support the following for fixed access: 

- policy management, 

authentication for WLAN terminals and fixed devices, 

- charging 

The EPS shall be capable to set operator policies to support simultaneous access to PLMN services and traffic 
offloading to the fixed network. 

Interworking shall support the following scenarios: 

When traffic is routed via EPC 

- When H(e)NB is being used and traffic is offloaded in the local wireline network 

- When WLAN is being used and traffic is offloaded in the local wireline network (i.e. non-seamless WLAN 
offloading) 

Additionally the Evolved Packet System shall be able: 

to minimize QoS and Policy management signalling overhead while interworking between the fixed access and 
Evolved Packet Core. 

- to route different simultaneously active PDN connections through different accesses while interworking between 
the fixed access and Evolved Packet Core. 
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- to route different IP flows belonging to the same PDN connection through different accesses while interworking 
between the fixed access and Evolved Packet Core. 

The requirements for mobility in chapter 7.1.3 apply also to interworking between the fixed access and Evolved Packet 
Core. 

5.2 Void 

5.3 Void 



6 Basic capabilities 

6.1 Support of IP traffic 

6.1 .1 Support of increased IP traffic demand 

The Evolved Packet System shall be able to provide guaranteed QoS for services and use the resources of the Evolved 
Packet System with high efficiency i.e. ensure that quality conditions for a particular communication are fulfilled 
without deterioration between the communicating end-points. 

6.1.2 Void 

6.1.3 Void 

6.1 .4 Support of basic IP connectivity 

Following registration on the network, the Evolved Packet System shall maintain an IP connectivity with the UE. 
Following registration it shall be possible for an UE to send and receive IP packets. 

6.1 .5 Support of IP multicast service 

The Evolved Packet System shall support IP multicast service. 

6.2 IP session control 

The Evolved Packet System shall provide for session mobility and session adaptation to terminal capabilities, user 
preferences, subscriber priorities, network conditions and/or other operator-defined criteria. Session adaptation shall be 
under the control of the operator. 

The Evolved Packet System shall support session control for multi-party sessions (e.g. user-to-group) and shall provide 
a scaleable solution. 

In order to support the efficient routing of IP traffic, local breakout (see Section 7.1.2) shall be supported. 

The Evolved Packet System shall support a UE having simultaneously more than one active PDN connections 
exchanging traffic with more than one peer (external network or other UE), when the network policies and user 
subscription allow it. 

If a UE is under the coverage of 3GPP access and one or more non-3GPP accesses, it shall be possible for the UE to 
communicate using multiple accesses simultaneously. 

The Evolved Packet System shall provide the system operator with the means to control the number of simultaneously 
active PDN connections and combinations thereof to and from a UE. 
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A single application running on the UE shall not be required to send and receive traffic through multiple PDNs. 
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6.3 Quality of Service 



The Evolved Packet System shall have the ability to provide a quality of service equal to or better than the QoS 
requirements specified for GSM and UMTS. Quality of Service from the customer's perspective is to be considered in 
phases as specified in ETSI TS 102 250-1 [6]. 



Network 
Access 



Service 
Access 



Service 
Retainability 



Service 
Integrity 



Figure 2: Phases of service use from customer's point of view 

Figure 2 shows the different phases (Quality of Service aspects) during service use from the customer's point of view. 
The meaning of these QoS aspects are: 

1) Network Access: The network indication on the display of the mobile is a signal to the customer that he can use the 
service of this network operator (or any other means to indicate to the user that a network is available). 

2) Service Access: If the customer wants to use a service, the network operator should provide him as fast as possible 
access to the service. 

3) Service Integrity: This describes the Quality of Service during service use. 

4) Service Retainability: Service Retainability describes the termination of services (in accordance with or against the 
will of the user). 

In particular the Evolved Packet System shall provide for the following: 

- There should be no perceptible deterioration of audio quality of a voice call during and following handover 
between dissimilar CS and PS access networks, and transitions between PS access networks supporting different 
IP protocol versions. 

- There should be no loss of data, as a result of handovers between dissimilar fixed and mobile access systems, 
including those that support different versions of the IP protocol. 

- There should be no discernable difference in perceived service quality for users receiving services via unicast 
and users receiving the same service via multicast. 

- The Evolved Packet System shall support QoS differentiations for unicast bearers. 

- The Evolved Packet System shall support QoS backwards compatibility to earlier 3 GPP QoS releases. 

- It shall be possible for the Evolved Packet System to maintain end-to-end QoS without modification when the 
terminal moves from one access system to a new access system, and the new access system supports the required 
QoS. 

- It shall be possible for the Evolved Packet System to change QoS, when the terminal moves from one access 
system to a new access system and the new access system can not provide the same QoS as the old access system 
or the new access system can provide higher QoS. 

- It shall be possible for the Evolved Packet System to support service continuity for a terminal changing access 
system and the new access system cannot provide the same QoS as the old one. 

- The Evolved Packet System shall support transport QoS differentiations for multicast bearers. 

- It shall be possible for the Evolved Packet System to maintain QoS within a multicast session without QoS 
changes for other members of the session when a terminal joins or leaves the multicast session or moves to a 
new access system. 

- The Evolved Packet System network shall support a minimum of 8 levels of QoS in parallel. 

- The Evolved Packet System network shall support a minimum of 4 parallel RT QoS levels with the appropriate 
QoS differentiation. 
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NOTE 1 : The requirement for the number of simultaneously supported QoS levels is independent of any MBMS 
QoS levels. 

Multiple RT services, with similar QoS requirements, shall be served by the same RT QoS level and multiple 
NRT services, with similar QoS requirements, shall be served by the same NRT QoS level. 

The maximum number of parallel RT and NRT services shall not be limited in the Evolved Packet System 
including the UE. Only the number of parallel RT and NRT QoS levels are limited to the upper value supported 
by the Evolved Packet System. 

- Differentiated handling based on QoS is needed for different traffic types. 

- The Evolved Packet System shall support parallel operation of RT and NRT services per user. 

NOTE 2: The different QoS levels provided for RT and NRT services would be differentiated with regards to e.g. 
maximum end-to-end delay, packet size, packet drop percentage, etc. Bandwidth is not used to define a 
QoS level. 

6.4 Support of Multicast and Broadcast Services 

The Evolved Packet System shall be able to support Multicast and Broadcast Services which shall be enhanced 
especially from some aspects, e.g. optimized service provisioning procedures, better performance compared to current 
MBMS system, and support of multiple access systems. 

6.5 Support of Emergency Calls 

The Evolved Packet System shall support IMS emergency calls applicable to the PS domain, defined in TS 22.101 [21] 
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7 Multi-access and seamless mobility 

7.1 Mobility management 

7.1 .1 Heterogeneous access systems mobility 




Figure 3: Heterogeneous access system mobility between 3GPP Legacy Systems or E-UTRAN and 
non 3GPP Access Systems including Fixed Access systems 

The Evolved Packet System shall support mobility between heterogeneous access systems. 

The Evolved Packet System shall provide mobility mechanisms to support frequent handovers within and across 3 GPP 
legacy systems or E-UTRAN and non 3 GPP access systems in order to avoid service degradation. 

The Evolved Packet System shall support mobility mechanisms that accommodates access systems within Rel-7 and 
earlier. 

7.1.2 Local breakout 

The Evolved Packet System shall allow for local breakout. Local breakout means that for a user which makes mobility 
within and across one operator-defined network region, routing is optimized such that user plane traffic does not need to 
leave the current region. An operator may define network regions e.g., according to administrative domains. Local 
breakout is applicable for user-to-user traffic as well as for 3GPP-operator provided services (including internet access). 

Local breakout shall be allowed independently from the access system being used. 

Local breakout shall be allowed in both the non-roaming and the roaming case. 

The use of local breakout shall be authorised by the HPLMN. If local breakout is not authorised, the user plane traffic 
shall be handled in the home routed mode. 
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7.1 .3 Fixed Access Systems 

The Evolved Packet System shall be able to support fixed access systems with very limited or no mobility functionality. 

The Evolved Packet System shall be able to support mobility within and across 3GPP and non-3GPP access systems 
including fixed access systems 

7.1 .4 Service continuity 
7.1.4.1 General 

Service shall be maintained during and following changes of 3GPP access systems and non 3GPP systems. 

Service shall be maintained during and following a change of network in either direction between a Rel-7 and earlier 
network and an Evolved Packet System. 

It shall be possible to support Inter-PLMN handover with seamless service continuity within a 3GPP specified access 
system (UTRAN, E-UTRAN). 

When the access system changes, Multicast and Broadcast services shall be able to continue with their corresponding 
Multicast and Broadcast services, if the corresponding services are provided in the target access system. 

Note: Corresponding Multicast and Broadcast services are the Multicast and Broadcast services in the target access 
system which is associated to the Multicast and Broadcast services in the source access system, providing similar 
service experience, e. g. with same content but different bit-rate. 



Evolved PLMN-A 



Evolved PLMN-B 




Figure 4: Inter-PLMN handover with seamless service continuity within a 3GPP specified access 

system 

7.1 .4.2 Service continuity at domain and RAT change for TS 1 1 , TS 12 and 

equivalent PS service 

It shall be possible to support continuity of an established voice call, i.e. between a TSl 1, TS12 and an equivalent PS 
service, when the UE moves between two different domains and RATs. The user experience shall be as far as possible 
unaffected by the change of domain and RAT. The RAT change procedure executed to enable service continuity for an 
established voice call shall target an interruption time not higher than 300 ms. 

RAT change and domain selection shall be under the control of the registered PLMN. When the UE is roaming, it shall 
be possible for the VPLMN to take into account any user"s HPLMN operator policy. 

To support service continuity of an established voice call a UE shall not be required to support simultaneous radio 
transmission via different 3GPP defined RATs 

NOTE: In the case of CS emergency calls (TSl 2) the service continuity at domain and RAT change can only be 
performed if IMS emergency calls are supported by the target system. 



ETSI 



3GPP TS 22.278 version 11.6.0 Release 11 17 ETSI TS 122 278 V1 1.6.0 (2012-09) 

7.1 .4.2A Voice Call Service continuity between 3GPP defined RATs and non 3GPP 
defined RATs 

Continuity of an established voice call, i.e. between a TSl 1 and an equivalent PS service, when the UE moves between 
3GPP defined RATs and non 3GPP defined RATs, shall be supported provided that the non-3GPP defined RATs is 
connected to the 3 GPP system via the Evolved Packet Core. 

The user experience shall be as far as possible unaffected by the change of RAT. 

7.1 .4.3 Service continuity between E-UTRAN and 3GPP2 accesses on Evolved 
Packet Core 

The Evolved Packet System shall support bidirectional service continuity between cdma2000 IxRTT Revision A [8], 
[9], [10], [11], [12], [13], [14], [15] and E-UTRAN. 

NOTE 1: if bi-directional support is not practical, service continuity from E-UTRAN to cdma2000 IxRTT Revision 
A should have the higher priority. 

NOTE 2: The CS component of cdma2000 IxRTT Revision A is not expected to be connected to the Evolved 
Packet Core. 

The Evolved Packet System shall support bidirectional service continuity between cdma2000 HRPD (IxEV-DO) 
Revision A [17], [14], [15], [16] and E-UTRAN for best effort and real-time applications. 

The Evolved Packet System shall support bidirectional service continuity between cdma2000 HRPD (IxEV-DO) 
Revision [18], [14], [15], [16] and E-UTRAN for best effort applications. 

7.1 .4.4 Service continuity between 3GPP and WiMAX access on Evolved Packet 
Core 

The Evolved Packet System shall support bidirectional service continuity between Mobile WiMAX [20], [22], [23], 
[24] and GERAN PS. 

The Evolved Packet System shall support bidirectional service continuity between Mobile WiMAX [20], [22], [23], 
[24] andUTRANPS. 

The Evolved Packet System shall support bidirectional service continuity between Mobile WiMAX [20], [22], [23], 
[24] and E-UTRAN. 

NOTE: The above requirements assume that the service continuity takes place through the Evolved Packet Core. 

7.1 .5 Access network discovery 

To avoid unnecessary background scan by the UE and to facilitate service continuity by the UE it shall be possible for 
the VPLMN and the HPLMN to provide the UE with access network information pertaining to locally supported non- 
3GPP access technologies, in a resource efficient and secure manner. This mechanism is meant to facilitate changes, 
including service continuity, between 3 GPP access systems and non 3 GPP access systems and vice versa. The 
information may be restricted to the access technologies the UE can use. To reduce battery drain, a UE should minimise 
the frequency of scanning for different access technologies. 

When discovering non-3 GPP accesses a UE shall be able to receive information from a non-3 GPP access network 
concerning to which PLMN, or PLMNs, the non-3GPP access network provides access. 

Note: The capability to provide such information by a non-3GPP access network is out of scope of 3GPP. 

When a UE receives service via a non-3 GPP access it shall be possible for the PLMN that provides the non-3 GPP 
access to indicate local availability of 3GPP access to the UE„ in a secure manner, subject to capabilities of the non- 
3 GPP access network. 
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7.1 .6 Steering of access 



When a UE is accessing the Evolved Packet Core via E-UTRA, the operator of the PLMN that provides the access 
(registered PLMN or RPLMN for short) may request the UE to use - any or a specific - non-3 GPP RAT. Similarly, if a 
UE is accessing the Evolved Packet Core via a non-3 GPP RAT then the RPLMN may want to request the UE to use E- 
UTRA. The reason for such steering may be load balancing (for camped- and traffic load balancing), operator policy, 
private networks/home cells, service based mobility control etc. 

The RPLMN shall be able to download on the UE a list of preferred access technologies in priority order. If, while the 
UE is registered on that PLMN, an access technology with higher priority than the one currently used is detected, the 
UE shall attempt to use the higher priority access network to access the RPLMN. 

The UE shall only perform access technology selection within the RPLMN. 

In case the UE is connected to the PLMN via a non-3GPP access, then the PLMN reselection procedures specified for 
that access technology may be executed. 

Note 1 : The PLMN operator may provide access to the Evolved Packet Core either through an own access network 
(E-UTRA or non-3 GPP access) or in collaboration with an access network operator that operates a non- 
3 GPP access network. 

Note 2: A specific non-3GPP RAT may e.g. be identified by RAT type and the access network name (as advertized 
by the access network), or a list of access network names. 

The HPLMN may also provide the UE with a list of preferred access technologies in priority order for use in the 
RPLMN. Only one list of preferred access technologies can be active at a time and the list provided by the RPLMN 
takes precedence over the list provided by the HPLMN. The list of preferred access technologies received from the 
VPLMN is specific to that VPLMN and PLMNs equivalent to it. 

7.1.7 CS fallback 

7.1.7.1 General 

For those services delivered via the HPLMN that the HPLMN only supports in the CS domain (e.g. voice services), 
when such services are invoked while the UE is configured to use CS Fallback and registered in the E-UTRAN (either 
in the HPLMN or in a VPLMN), it shall be possible for the EPS to request the UE to perform a change of radio access 
technology in order to deliver the service over UTRAN or GERAN or IxRTT. 

In the case of an incoming CS service to a UE that is registered for CS services and active in E-UTRAN, the EPS shall 
transfer the CLI to the UE if available and the calling party has not restricted the presentation, prior to triggering CS 
fallback. Depending on UE configuration and when the UE is in connected mode, the user or an application on behalf of 
the user may request to accept or reject CS fallback before performing a change of radio access technology. The default 
behaviour of the UE is to accept the CS fallback. 

7.1 .7.2 Roaming in a VPLMN not supporting CS fallback 

When a UE that is configured to use CS fallback registers over E-UTRAN in a VPLMN not supporting CS fallback the 
default behaviour of the UE is to attempt to select a GERAN/UTRAN/lxRTT CS radio access technology in the 
VPLMN or in a PLMN equivalent to the VPLMN. The default behaviour of the UE is not to autonomously attempt to 
(re-)select the E-UTRAN for the duration of the time the UE stays in a VPLMN and PLMNs equivalent to the VPLMN. 

The default behaviour may be changed based on user preference settings. 

The UE may offer the user to perform a PLMN scan and display the list of available PLMNs. The selection of a 
different PLMN is performed using the manual mode. 
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7.2 IFOM Service requirements 



Simultaneous active mode of operation is an optional capability for multimode UEs, which support 3GPP and WLAN 
access. UE supporting simultaneous active mode of operation between one set of technologies may not be capable to 
support simultaneous active mode of operation between a different technology set (e.g. due to radio interference 
limitations). 

The following requirements apply to the case of UEs with multiple interfaces which will simultaneously connect to 
3GPP access and one single WLAN access. 

- It shall be possible to provide service continuity when the UE moves from the 3GPP access to WLAN access and 
vice versa. 

- If the UE is under the coverage of more than one access, including 3GPP and WLAN accesses and 
communicates using multiple accesses simultaneously, it shall be possible to select one access when a flow is 
started and re-distribute the flows to/from a UE between accesses while connected. 

- It shall be possible for the operator to enable and control via policies the simultaneous usage of multiple 
accesses. 

- It shall be possible to distribute IP flows to/from a UE between available accesses based on the characteristics of 
the flows and the capabilities of the available accesses, subjected to user's preferences and operator's policies. 

It shall be possible for the operator to define policies for the control of the distribution of IP flows between 
available accesses. Each policy shall include a list of preferred accesses and whether the policy may be 
overridden by the user's preferences. 

NOTE: The possibility of manual selection or user override is not precluded. 

These policies may be defined per APN, per IP flow class under any APN or per IP flow class under a specific 
APN. The IP flow class identifies a type of service (e.g. IMS voice) or an operator defined aggregation of 
services. 

The policies apply with the following priority order: 

1. Policies per IP flow class under a specific APN. 

2. Policies per IP flow class under any APN. 

3. Policies per APN. 

- Distribution of flows to/from a UE between available accesses based on the characteristics of the flows and/or 
the capabilities of the available accesses shall be possible for flows exchanged by both operator controlled (e.g. 
IMS) and non operator controlled (e.g. web and mail access) applications/services. 

- It shall be possible to move all the flows to/from a UE out of a certain access in case the UE loses connectivity 
with that access (e.g. UE moves out of coverage of a WLAN access while maintaining connectivity through the 
3GPP access). 

- Re-distribution of flows to/from a UE between accesses may be triggered by changes to the characteristics of the 
flows (e.g. QoS requirements) or the capabilities of the available accesses (e.g. due to network congestion, 
mobility event, or UE discovers a new access) during the connection. 



8 Performance requirements for the Evolved Packet 

System 

The Evolved Packet System comprises the Evolved Packet Core together with the evolved radio access network (E- 
UTRA and E-UTRAN). A study of the Evolved Packet Core can be found in TS23.882 [7] and the evolved radio 
access network E-UTRA and E-UTRAN in TR25.913 [4]. 
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The performance objectives for the Evolved Packet System include higher user data rates, reduced latency, improved 
system capacity and coverage, reduced network complexity and lower operating costs. 

The Evolved Packet System shall meet or exceed the following performance criteria: 

a) The radio access network shall be capable of supporting instantaneous peak packet data rates of 100 Mbps on the 
radio access bearer downlink to the UE and 50 Mbps on the uplink. 

b) The Evolved Packet System shall be capable of providing lower user and control plane latency when compared 
to existing 3 GPP access networks. The maximum delay should be comparable to that for fixed broadband 
Internet access technologies, [e.g. less than 5ms in ideal conditions] 

c) The system shall be capable of supporting large volumes of mixed e.g. voice, data and multimedia traffic. 
Enhanced load balancing and steering of roaming methods should be used to minimise cell congestion. 

d) The level of system complexity and mobility management signalling shall be optimised to reduce infrastructure 
and operating costs. UE power consumption shall also be minimised accordingly. 

e) For the Evolved Packet System the interruption time during handover of RT and NRT services shall be kept to 
minimum and shall not exceed the values defined in TR 25.9 13 [4]. 
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Security and privacy 



9.1 General 

The Evolved Packet System shall provide a high level of security and privacy for users and Evolved Packet System 
operators. 

9.2 Security requirements 

The Evolved Packet System shall provide a high level of security, equivalent or better than Rel-7 3 GPP systems. 

Any possible lapse in security in one access technology shall not compromise security of other accesses. 

The Evolved Packet System should provide protection against threats and attacks including those present in the Internet. 

The Evolved Packet System shall support information authenticity between the terminal and Evolved Packet Systems. 

The Evolved Packet System shall allow for a network to hide of internal network elements from the UE. 

Security policy shall be under the control of the home operator. 

The security solution should not interfere with service delivery or 3 GPP inter-access handovers in a way that is 
noticeable to end-users or service providers. 

Appropriate traffic protection measures should be provided by the Evolved Packet System. 

The Evolved Packet System shall provide appropriate mechanisms to enable lawful intercept. 

The Evolved Packet System shall ensure that no unauthorized user can obtain a legitimate IP address that can be used to 
establish conmiunication or enable malicious attacks on evolved system entities. 

Release 99 or later Releases' USIM application on the UICC is required to authenticate a user in an Evolved Packet 
System and hence allowing the user to get services in the Evolved Packet System according to her/his subscription. 

Note: The above requirement is applicable when providing access to the EPC via E-UTRAN. 

Once authenticated via a 3 GPP or Evolved Packet System, the USIM shall not be required to re-authenticate upon 
changing between these systems, unless specifically requested by the operator (PLMN). 

NOTE: It may be possible to use other applications on the UICC in order to provide authentication on the 3 GPP 
or Evolved Packet System (e.g. for connection to IMS). In addition, in case it is desirable to improve the 
level of security or to add new security mechanisms for accessing the Evolved Packet System compared 
to the one provided in Rel-7, a revised/upgraded application on the UICC may be required. 



9.3 Privacy requirements 



The Evolved Packet System shall provide several appropriate levels of user privacy including communication 
confidentiality, location privacy, and identity protection. 

The privacy of the contents, origin, and destination of a particular communication shall be protected from disclosure to 
unauthorised parties. 

The Evolved Packet System shall be able to hide the identities of users from unauthorised third parties. 

It shall be possible to provide no disclosure, at any level of granularity, of location, location-related information, e.g. 
geographic and routing information, or information from which a user"s location can be determined, to unauthorised 
parties, including another party on a communication. 
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10 Charging Aspects 



The Evolved Packet System shall support various charging models including all those supported by the 3 GPP system 
contained within TS22.115 [5] . 

Charging models that shall be supported by the Evolved Packet System include (non-exhaustive list): 

- calling party pays 

- charging based on assured QoS 

- charging based on the transport 

- charging based on an event 

- charging based on content 

- charging adjustment (e.g. based on subscription bands) 

- alternate party charging 

The Evolved Packet System shall also be able to support introduction of new charging schemes including online and 
offline schemes, and charging schemes for the multi-access system environment 

Charging mechanisms of the Evolved Packet System shall provide (non-exhaustive list): 

- Cost effective Control and Charging of IP Flows 
Perform online charging 

- Support differentiated charging including zero rating of the bearer and event charging 

- Awareness of subscriber identity, time-of-day, roaming status, QoS, Service input etc 
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Annex A (informative): 
Requirements for further study 

A.1 Management of access networks 

The Evolved Packet System shall be able to allow for self-managing technologies (e.g. Plug-and-Play) for dynamically 

adding and removing non-3 GPP defined access networks. 

Such self-managing technologies shall take into account the Evolved Packet System and access network policies. 

E.g. depending on such policies it shall be possible to for the 3GPP system operator to request encryption of user traffic 
that is transmitted over the access network. 

NOTE 1: The non-3GPP access network needs to have defined interworking with 3GPP. 

An example could be a WLAN (operated by some WLAN operator) that can, if needed, automatically be connected to a 
PLMN to serve as an I- WLAN access. This would enable the PLMN operator to provide additional access resources on 
a dynamic basis and to provide service to more customers (e.g. at mass events). 

NOTE 2: The degree of automation provided for network attachment is yet to be determined, but is intended to 
simplify (or completely automate) administration procedures. 

A.2 Use cases for Fixed Mobile Convergence 

A family has purchased a family subscription plan that is independent of access (e.g. fixed or wireless) and location 
(e.g. both when at home and away from home). The subscription contains at least the following components: 

■ Internet access: Operator specific service such as firewall and content filtering (parental control) independent 
of access for selected devices within the family. The service should be available at home, within the home 
mobile network and when roaming to a visited mobile network. 

■ Voice/Multimedia: QoS and mobility between home WLAN and LTE wide area 

■ Charging schemas connected to access type, preference and location 

■ Video: Premium Video on Demand Service incl. guaranteed bandwidth and QoS regardless of access network. 
Description 

Use case 1: Internet access with Parental control and personal firewall 

The kids leave their house and take a bus to their grandparents" house. 

The operator specific services, like parental control and personal firewall, are invoked for specific users and terminals 
from both fixed network and from mobile network; this allows the kids to get the same service and filtering inside the 
home, in the bus going to grandparents and at the grandparents. In this use case the grandparents have a separate service 
provider than the family but the services will still be provided by the service provider where the family has a 
subscription. 

Use case 2: Voice/Multimedia and Charging 

The father travels home after work while talking on the phone with his colleague. 

The ongoing Voice/Multimedia call between the father and his colleague is maintained while switching over between 
LTE Wide area and residential fixed broadband WLAN network. Once the call is switched over to WLAN charging for 
home-based access is applied. Bandwidth and QoS is maintained for the duration of the call to guarantee the same 
service delivery. 

Use case 3: Video 
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The kids in the backseat of the car are watching an Internet TV show on their laptop using LTE while driving home 
from the grandparent" s house. 

The TV show is sent from an Internet TV provider. Once home the terminal detects indoor WLAN coverage where the 
subscriber has a WLAN Residential Gateway connected to his Fixed Broadband network. The user or the terminal 
automatically may select to switch the IP connection to the wireline broadband connection and enable the user to 
resume watching the same TV show on the same laptop, possibly with a better quality picture as allowed by the 
available bandwidth, user-specific policy, network policy and QoS setting. 

Use case 4: H(e)NB/Femtocell 

A subscriber desires to improve coverage and access speed for their 3GPP device in their home. They purchase and 
install a small eNodeB (Femtocell AP) device for their home which attaches to the home LAN and establishes a 
connection back to the subscriber" s mobile service provider network. The mobile network provider coordinates with the 
broadband access provider to deliver proper bandwidth and QoS to support a good QoE for calls and data sessions made 
within the home that access services from the mobile network. The Femtocell also allows some types of data traffic to 
be shared with the home LAN, including traffic for Internet applications. Local traffic can be discerned and accounted 
for differently than traffic that is carried on the mobile network. 

Use case 5: Application Mobility 

A subscriber is in a multimedia call on their mobile device, and then wishes to change the device they are using to a 
fixed network attached device (e.g. Set Top Box / TV). The multimedia call is handed over from the mobile network to 
the fixed network after the subscriber chooses to transfer the multimedia call to a STB / TV. Bandwidth and QoS is 
maintained for the large screen experience to be meaningful. Accounting and settlement is supported among the 
application and network service providers, and reflects the changes to the access technology and required bandwidth. 

Use case 6: Common Quota 

A Common Quota (CQ) can be assigned for both fixed and mobile accesses for a limited time period for a defined set of 
subscriptions. During each session the network elements monitor the CQ which may be consumed by one or more 
devices over either the wireless or fixed networks. 

When a defined percentage of the CQ and/or all the CQ has been consumed, one or more subscribers in the defined set 
can be notified of the event (e.g. via SMS and/or email). 

When the CQ has been consumed the access to the services is blocked. 

Use case 7: Video On Demand Service 

Video On Demand (VoD) service is provided to the subscriber via the Set Top Box to the TV or to the PC. A user 
orders a VoD service interacting with the VoD infrastructure, which sends a resource request to the network. The user 
may also request mid-session requests triggering the increase/decrease of network resources. The requests will be 
accepted or rejected according to the available network resources. 

Use case 8: Broadband Access Wholesale 

In Broadband network the wholesale scenario is quite important as it may be required by the regulation, known as 
unbundling (access, connectivity and services). For example the operator of the broadband access network lease/sell 
transport of the connection through its own network from the user to the buyer / leased network. So in the wholesale 
scenario the renting operator has the end-to-end Service responsibility to the customer and is viewed as the 'Retailer' of 
the service or application. While the leasing network operator has the responsibility for the access network and for the 
connectivity. 
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Annex B (Normative): 

Evolved Packet System (EPS) applicable specifications 

The specifications listed in clause B.lcontain requirements applicable to the Evolved Packet System (EPS). 



B.1 EPS Applicable Specifications 



TS 


Title 


21.905 


Vocabulary for 3GPP Specifications 


22.011 


Service accessibility See note 


22.016 


International Mobile Equipment Identities (IMEI) 


22.022 


Personalisation of Mobile Equipment (ME); Mobile functionality specification 


22.030 


Man-Machine Interface (MMI) of the User Equipment (UE) 


22.038 


USIM Application Toolkit (USAT/SAT); Service description; Stage 1 


22.041 


Operator Determined Call Barring 


22.042 


Network Identity and Time Zone (NITZ) service description; Stage 1 


22.066 


Support of Mobile Number Portability (MNP); Stage 1 


22.067 


enhanced Multi-Level Precedence and Pre-emption service (eMLPP); Stage 1 


22.071 


Location Services (LCS); Service description; Stage 1 


22.078 


Customised Applications for Mobile network Enhanced Logic (CAMEL) 


22.101 


Service Principles 


22.105 


Services and Service Capabilities 


22.115 


Charging and Billing 


22.129 


Handover requirements between UTRAN and GERAN or other radio systems 


22.146 


Multimedia Broadcast/Multicast Service (MBMS); Stage 1 


22.153 


Multimedia priority service 


22.173 


IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; 
Stage 1 


22.174 


Push service; Stage 1 


22.182 


Customized Alerting Tones (CAT) Requirements 


22.226 


Global text telephony (GTT); Stage 1 : Service description 


22.228 


Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1 


22.233 


Transparent end-to-end packet-switched streaming service; Stage 1 


22.234 


Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking 


22.240 


Service requirements for 3GPP Generic User Profile (GUP); Stage 1 


22.242 


Digital Rights Management (DRM); Stage 1 


22.246 


Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1 


22.250 


IP Multimedia Subsystem (IMS) Group Management; Stage 1 


22.259 


Service requirements for Personal Network Management (PNM); Stage 1 


22.279 


Combined Circuit Switched (CS) and IP Multimedia Subsystem (IMS) sessions; Stage 1 


22.340 


IP Multimedia Subsystem (IMS) messaging; Stage 1 


Note: In case the UE is connected to the PLMN via a non-3GPP access, then the PLMN (re)selection procedures 
specified for that access technology may be executed. 
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Annex B1 (Informative): Void 
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Annex C (informative): 
Change history 



Change history 


TSG SA# 


SA Doc. 


SA1 Doc 


Spec 


CR 


Rev 


Rel 


Cat 


Subject/Comment 


Old 


New 


Wl 


SP-35 


SP-070128 


SI -0701 87 


2? 278 


0001 


2 


Rel-8 


F 


Clarification on QoS classes for 
evolved 3GPP system 


8.0.0 


8.1.0 


SAE-R 


SP-35 


SP-070127 


SI -0701 97 


22 278 


0002 


- 


Rel-8 


B 


Provision of access network 
information to the UE 


8.0.0 


8.1.0 


SAE-R 


SP-36 


SP-070365 


SI -070806 


22.278 


0003 


3 


Rel-8 


B 


Requirement for handovers 
between LTE and 3GPP2 
access networks 


8.1.0 


8.2.0 


SAE-R 


SP-36 


SP-070369 


SI -070556 


22.278 


0005 




Rel-8 


D 


Editorial correction for 
performance requirements for 
evolved 3GPP system 


8.1.0 


8.2.0 


SAE-R 


SP-36 


SP-070367 


SI -070807 


22 278 


0006 


1 


Rel-8 


B 


Performance requirements for 
evolved 3GPP system 


8.1.0 


8.2.0 


SAE-R 


SP-36 


SP-070370 


SI -070764 


22.278 


0008 


1 


Rel-8 


B 


Requirement for national 
roaming between LTE-only 
operators and 2G/3G-only 
operators 


8.1.0 


8.2.0 


SAE-R 


SP-36 


SP-070483 


SI -070805 


22 278 


0009 


5 


Rel-8 


B 


Requirements for service 
continuity between 3GPP 
system and WilVlAX 


8.1.0 


8.2.0 


SAE-R 


SP-37 


SP-070566 


SI -071 324 


22 278 


10 


2 


Rel-8 


D 


Addition of 3GPP reference for 
the evolved 3GPP packet 
system (EPS) 


8.2.0 


8.3.0 


SAE-R 


SP-37 


SP-070566 


SI -071 096 


22.278 


11 


1 


Rel-8 


B 


IVIultiple IP session 


8.2.0 


8.3.0 


SAE-R 


SP-37 


SP-070566 


SI -071 097 


22 278 


12 


1 


Rel-8 


B 


Voice service continuity between 
3GPP RAT and non 3GPP RAT 


8.2.0 


8.3.0 


SAE-R 


SP-37 


SP-070566 


SI -070994 


22.278 


13 


1 


Rel-8 


B 


Alignment of terminology with 
SA2 


8.2.0 


8.3.0 


SAE-R 


SP-37 


SP-070566 


SI -071 122 


22.278 


14 


1 


Rel-8 


B 


Access network discovery 


8.2.0 


8.3.0 


SAE-R 


SP-38 


SP-070855 


SI -071 856 


22 278 


0021 


2 


Rel-8 


C 


Support for efficient delivery of 
text-based broadcast messages 


8.3.0 


8.4.0 


AIPN-SAE 


SP-38 


SP-070855 


S1-071912 


22.278 


0022 


1 


Rel-8 


B 


Emergency Call Support 


8.3.0 


8.4.0 


AIPN-SAE 


SP-38 


SP-070856 


S1-071913 


22 278 


0015 


3 


Rel-8 


B 


Enhancements to Access 
network discovery and steering 
of access 


8.3.0 


8.4.0 


AIPN-SAE 


SP-38 


SP-070856 


SI -071 91 5 


22.278 


0017 


1 


Rel-8 


F 


IVIuIti -access IVIBIVIS 


8.3.0 


8.4.0 


SAE-R 


SP-38 


SP-070856 


SI -071 91 6 


22.278 


0018 


1 


Rel-8 


B 


QoS change requirement 
clarification 


8.3.0 


8.4.0 


SAE-R 


SP-38 


SP-070929 




22.278 


0024 


2 


Rel-8 


C 


Addition of list of applicable 
specifications for the EPS and 
amended scope 


8.3.0 


8.4.0 


AIPN-SAE 


SP-40 


SP-080306 


SI -080740 


22.278 


0028 


2 


Rel-8 


F 


Clarification of EPS access 
using pre-Rel-8 USIIVIs 


8.4.0 


9.0.0 


AIPN-SAE 


SP-40 


SP-080306 


SI -080720 


22.278 


0030 


1 


Rel-8 


F 


WIIVlAX Forum specification 
reference in TS 22.278 


8.4.0 


9.0.0 


AIPN-SAE 


SP-40 
















Creation of v.9.0.0. Content 
identical to 8.4.0 + CRs 28r2 
and 30r1 (but not including CR 
27r1 , applicable to Rel-8 only, to 
remove Features which Stage 3 
was not completed on time) 


8.4.0 


9.0.0 




SP-41 


SP-080495 


SI -08201 8 


22 278 


0037 


- 


Rel-9 


A 


Service continuity (mirror to a 
Rel-8 CR) 


9.0.0 


9.1.0 


AIPN-SAE 


SP-41 


SP-080639 


- 


22 278 


0039 


3 


Rel-9 


A 


Access Network Discovery and 
Steering of Access 


9.0.0 


9.1.0 


AIPN-SAE 


SP-41 


SP-080495 


SI -082398 


22 278 


0041 


2 


Rel-9 


A 


Update IP session control and 
local breakout requirements 


9.0.0 


9.1.0 


AIPN-SAE 


SP-41 


SP-080495 


S 1-082386 


PPP78 


0043 


3 


Rel-9 


A 


Requirement on support of CS 
Fallback 


9.0.0 


9.1.0 


AIPN-SAE 


SP-41 


SP-080652 




22.278 


0043 


5 


Rel-9 


A 


De-implementation of CR43r3 
and implementation of 43r5, as 
approved during SA#41 


9.1.0 


9.1.1 


AIPN-SAE 


SP-42 


SP-080774 


SI -0831 14 


22.278 


0045 


- 


Rel-9 


A 


Deletion of redundant reference 


9.1.1 


9.2.0 


AIPN-SAE 


SP-42 


SP-080783 


SI -083465 


22 278 


0049 


2 


Rel-9 


B 


Terminal Identification of 3GPP 
and 3GPP2 devices 


9.1.1 


9.2.0 


TEI9 


SP-42 


SP-080778 


SI -084334 


22.278 


0051 


1 


Rel-9 


B 


Support for Multimedia Priority 


9.1.1 


9.2.0 


AIPN-SAE 
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Service in EPS 








SP-42 


SP-080783 


SI -084368 


22.278 


0054 


1 


Rel-9 


C 


EPS operational deployment 
and mobility optimization 


9.1.1 


9.2.0 


TEI9 


SP-42 


SP-080783 


SI -084069 


22 278 


0055 


- 


Rel-9 


B 


Removal of chapter 6.1 .2 and 
6.1.3 


9.1.1 


9.2.0 


TEI9 


SP-42 


SP-080783 


SI -084425 


???78 


0056 


3 


Rel-9 


D 


Enhanced ANDSF 
Requirements 


9.1.1 


9.2.0 


TEI9 


SP-42 


SP-080783 


SI -08441 4 


22.278 


0057 


1 


Rel-9 


C 


Basic support for multiaccess 


9.1.1 


9.2.0 


TEI9 


SP-42 


SP-080783 


SI -084363 


22 278 


0058 


1 


Rel-9 


B 


Adding an appendix with FIVIC 
uses cases to 22.278 


9.1.1 


9.2.0 


TEI9 


SP-44 


SP-090417 


S1- 
091153rev 


22 278 


0062 


2 


Rel-9 


A 


Access Technology Selection 
across PLIVINs 


9.2.0 


9.3.0 


SAES 


SP-44 


SP-090371 


SI -091 169 


22.278 


0066 


- 


Rel-9 


A 


IVIove sentence about non-3GPP 
access 


9.2.0 


9.3.0 


SAES 


SP-44 


SP-090371 


SI -091 352 


22.278 


0067 


- 


Rel-9 


A 


Frequency of Scanning for 
Different Access Technologies 


9.2.0 


9.3.0 


SAES 


SP-45 


SP-090476 


SI -093272 


22 278 


0060 


4 


Rel-9 


A 


Alignment about 
accepting/rejecting CSFB 


9.3.0 


9.4.0 


AIPN-SAE 


SP-46 


SP-090843 


SI -094500 


22 278 


0070 


2 


Rel-9 


F 


One active policy ruleset in 
ANDSF 


9.4.0 


9.5.0 


eANDSF 


SP-46 


SP-090904 


- 


22.278 


0071 


7 


Rel-10 


B 


Adding of IFOIVI Requirements 


9.5.0 


10.0.0 


IFOM 


SP-47 


SP-100185 


SI -100236 


22.278 


0080 


5 


Rel-10 


B 


Requirements for Fixed IVIobile 
Interworking 


10.0.0 


10.1.0 


BBAI 


SP-49 


SP-1 00575 


SI -102056 


22.278 


0089 


_ 


Rel-10 


A 


Removal of references to 3GPP 
OSA 


10.1.0 


10.2.0 


TEI10 


SP-49 


SP-1 00582 


SI -102032 


22.278 


0083 


_ 


Rel-11 


B 


Adding a H(e)NB use case to 
FIVIC use cases 


10.1.0 


11.0.0 


BBAI 


SP-49 


SP-1 00582 


SI -102303 


22.278 


0084 


1 


Rel-11 


B 


Adding a Application IVIobility 
use case to FIVIC use cases 


10.1.0 


11.0.0 


BBAI 


SP-49 


SP-1 00582 


SI -102307 


22.278 


0086 


1 


Rel-11 


D 


Clarifications on FMC use cases 


10.1.0 


11.0.0 


BBAI 


SP-49 


SP-1 00582 


SI -102308 


22.278 


0085 


2 


Rel-11 


B 


Adding a Common Quota use 
case to FMC use cases 


10.1.0 


11.0.0 


BBAI 


SP-49 


SP-1 00582 


SI -102309 


22.278 


0087 


2 


Rel-11 


B 


New Requirements for Fixed 
Mobile Convergence scenario 


10.1.0 


11.0.0 


BBAI 


SP-50 


SP-1 00802 


SI -103263 


22.278 


0090 


1 


Rel-11 


F 


Clarifying the scenarios 
supported by FMC interworking, 
including building block II 


11.0.0 


11.1.0 


BBAI 


SP-50 


SP-1 00802 


SI -103266 


22.278 


0091 


2 


Rel-11 


B 


New Requirements for 
Enterprise Interworking scenario 


11.0.0 


11.1.0 


BBAI 


SP-50 


SP-1 00802 


SI -103242 


22.278 


0093 


3 


Rel-11 


B 


3GPP EPC based FMC 


11.0.0 


11.1.0 


BBAI 


SP-50 


SP-1 00802 


SI -103321 


22 278 


0095 


1 


Rel-11 


B 


Use cases for BBAI Building 
Block 3 - Converged scenario 


11.0.0 


11.1.0 


BBAI 


SP-50 


SP-1 00802 


SI -103323 


22.278 


0097 


- 


Rel-11 


B 


Evolved Packet Core support for 
fixed access 


11.0.0 


11.1.0 


BBAI 


- 
















LTE logo changed into LTE 
Advanced logo 


11.1.0 


11.1.1 


- 


SP-51 


SP-1 101 65 


SI -11 0297 


22.278 


0094 


2 


Rel-11 


B 


Scenarios for Interworking 
between Mobile Operators and 
Application Providers 


11.1.0 


11.2.0 


MOSAP 


SP-51 


SP-1 101 65 


SI -11 0404 


22.278 


0098 


3 


Rel-11 


B 


New requirements for MOSAP 


11.1.0 


11.2.0 


MOSAP 


SP-51 


SP-1 101 65 


SI -11 0302 


22.278 


0100 


2 


Rel-11 


B 


Use cases for MOSAP 


11.1.0 


11.2.0 


MOSAP 


SP-51 


SP-1 101 69 


S1-110181 


22.278 


0099 


2 


Rel-11 


B 


Fixed Broadband Access 
Network Requirements for BBAI 
Building Block 3 - Convergent 
scenario 


11.1.0 


11.2.0 


BBAI 


SP-52 


SP-1 10372 


SI -11 1223 


22.278 


0101 


2 


Rel-11 


B 


User consent-based charging 
use case for MOSAP 


11.2.0 


11.3.0 


MOSAP 


SP-52 


SP-1 10372 


S1-111412 


22.278 


0103 


2 


Rel-11 


B 


Non-collaboration requirements 
for MOSAP 


11.2.0 


11.3.0 


MOSAP 


SP-53 


SP-1 10575 


SI -11 2357 


22 278 


0110 


3 


Rel-11 


F 


MOSAP - Roaming LBO 
Architecture Correction 


11.3.0 


11.4.0 


MOSAP 


SP-56 


SP-1 20294 


S1-121328 


22 278 


0115 


2 


Rel-11 


F 


Removal of MOSAP 
requirements from Rel-1 1 Specs 


11.4.0 


11.5.0 


MOSAP 


SP-57 


SP-1 20525 


SI -122052 


22 278 


0117 




Rel-11 


B 


Removal of BB III - Fixed Mobile 
Convergence requirements from 
Rel-11 


11.5.0 


11.6.0 


BBAI 
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